fix(vscode): show board participants in message headers - #13957

What Problem This Solves

board_read tool headers showed only the generic parent task glyph, even when the result contained messages from several agents. Broadcast board_post routes also represented ALL recipients with two generic task glyphs. The message routes themselves had partial avatar support, but the UI did not identify all participants consistently.

Why This Change Was Made

The board_read renderer now collects unique concrete sender and recipient IDs from the returned messages and renders them in the header. Broadcast board_post routes use the active avatar roster to render concrete recipients, while retaining the old generic fallback when no roster is available. The main participant keeps the existing static task glyph.

The participant row uses a small non-overlapping layout. Overlapping the dot-grid avatars made the header difficult to read.

User Impact

Collapsed board message reads now show the parent glyph followed by the avatars for every concrete participant in the conversation. Broadcast posts show the known recipient avatars instead of generic placeholders. Direct message routes and the parent icon are unchanged.

Evidence

Before, the header only showed the generic task glyph:

After, it shows the parent glyph followed by both participant avatars:

Broadcast before, with two generic task glyphs for ALL:

Broadcast after, with the two known recipient avatars:

Validation:

• bun test tests/unit/board-tool-render.test.ts passed with multiple participants.
• bun run lint passed in packages/kilo-vscode.
• bun run bundle passed in packages/kilo-vscode.
• The board renderer fixture verifies both a populated broadcast roster and the empty worker-roster generic fallback.
• The Storybook browser fixture verified the read participant stack and the broadcast route with two recipient avatars.
• Package-wide typecheck remains blocked by existing story, asset, and dependency errors unrelated to this change.
• The isolated VS Code shell loaded the current bundle, but its isolated backend had no persisted transcript records, so a live Agent Manager transcript could not be opened.

CI follow-up:

• The failed visual job was caused by stale swarm-board.spec.ts assertions that still expected two generic icons for the composite broadcast. The updated expectation checks for one parent icon, one recipient avatar, and the participant stack.
• The empty worker-roster case now preserves the two-icon fallback.
• The later unit-test failure is from the merge ref's AgentManagerProvider.ts size guard (1901 lines against a 1900-line cap), unrelated to avatar behavior. The focused local architecture test passes after removing one blank line locally.
• CI was not rerun from this update.